1. Field of the Invention
This invention relates to middleware appliances and more particularly relates to dynamically provisioning clusters of middleware appliances.
2. Description of the Related Art
Service Oriented Architecture (SOA) middleware appliances such as WebSphere® DataPower® appliances from International Business Machines (IBM) are functionally purposed hardware appliances that perform traditional middleware intermediary functions such as protocol bridging and deep-content routing. The emergence of middleware-purposed hardware and lightweight middleware stacks has overcome the performance burden stemming from the increased processing requirements of SOA-based and middleware payloads.
Unfortunately, these advances have not come without challenges. For simplicity, SOA appliances are stand-alone hardware entities with minimal support for clustering or grouping of like-purposed appliances. However, SOA appliances are generally deployed in multiples of two or more to provide sufficient processing power and to meet high availability requirements. The end result is an administrative burden where a user must properly manage the SOA clusters together as a collective whole.
From a configuration point of view, protocols and management frameworks such as the Appliance Management Protocol (AMP) and IBM Tivoli® Composite Application Manager System Edition for WebSphere DataPower (ITCAMSE4WDP), have helped to reduce this burden by providing a mechanism for dynamically synchronizing configuration across like-purposed appliances via a container object referred to as a service domain. These service domains consist of one or more service objects that indicate how the appliance will function. At a high-level, a service domain corresponds to a deployed application or related applications.
However, provisioning service domains among appliances still proves difficult. At present, appliance owners over-provision their appliance clusters and use manual, ad-hoc strategies to provision their appliance clusters among competing services. A typical provisioning objective, known as service differentiation, is to allocate a percentage of Central Processing Unit (CPU) cycles in the entire appliance cluster to a given service domain; this percentage may change, based on whether the system is under- or over-loaded. For example, an administrator may wish to allocate up to 50% of total CPU cycles to a particular service domain in underloaded conditions and 70% in overloaded conditions.
Two known solutions exist for providing differentiated services. Both approaches assume the existence of an HTTP router/IP sprayer (sprouter) to distribute service load to the appliance cluster. The sprouter is a device without deep-content inspection intelligence that simply routes on, for example, a URL, and uses IP spraying to send traffic to appliance replicas.
In a first approach, a system administrator groups all middleware appliances in a single group and enables them all to process service requests for any given service. The appliances are manually configured with all service objects and their corresponding service domains enabled (ITCAMSE4WDP could dynamically copy this manual configuration from one device to the rest). The fronting IP sprayer forwards a service request to each of the middleware appliances, routing the request to the appropriate service port for service-specific processing. The service flow would then load-balance the requests to backing service replicas. This approach suffers from a number of drawbacks. First, in enabling all service domains on every appliance, it is very difficult to manually implement differentiated services across service domains competing for the same appliance resources.
While an IP sprayer can effectively spread the load amongst the different appliances, the IP sprayer cannot gauge the effect of a specific service request on CPU and thus cannot provide differentiated service amongst the competing service domains. For example, assuming that three middleware appliances are in use, if the administrator wishes to allocate up to 50% of total CPU to a particular service domain, the system as whole can only hope to evenly spread across the appliances, which, under overload conditions, leads to each service domain receiving ⅓ (33%) of the total CPU cycles. So rather than getting 50% CPU utilization for a service domain in a particular SOA appliance the maximum is 33%. A secondary problem is that it becomes nearly impossible to effect any spatial locality with this solution. Spatial locality involves focusing a service domain on specific middleware appliances to increase the likelihood that similar memory locations will be accessed repeatedly. In many realistic cases, performance can be improved by concentrating requests for a specific service domain together, for example, to increase cache hit rates.
In a second approach, the administrator statically allocates a portion of the appliances to each of the service domains. In this case, each middleware appliance is assigned one or more specific service domains that it will serve as opposed to each appliance receiving service assignments dynamically. In this way, service requests for a specific service domain are concentrated on specific appliances, thus achieving spatial locality. Further, the administrator can allocate appliances for service domains proportional to the intended capacity (and to some extent priority) for each individual service, thus achieving some level of differentiated service. However, this approach also has drawbacks. First, it is difficult to leverage unused resources of appliances serving one service for satisfying requests intended for overloaded appliance and its service. Therefore, under certain conditions, many of the overall system resources may be under-utilized. Second, the allocation process is manual and cannot adapt to changing request rates and prevailing conditions. This could lead to inefficient resource partitioning and ultimately violate intended differentiated service goals.
In summary, both known conventional solutions to the appliance provisioning problem result in (a) inefficient use of appliance resources, and, (b) the inability to provide actual service differentiation.